Proposal: Allow trailing comma in tuples & argument lists

[Neme12]

In languages like Pascal the semicolon was a used as a statement separator rather than a terminator, which was a always an annoyance and in my opinion also a design flaw. Languages that have come after have fixed that - but not for commas.

The missing comma causes issues when we put the comma separated list on multiple lines. It shows an extra line as modified in diffs and it makes it harder to reorder the items. The missing comma at the end is always a special case.

I would argue that the idea of a token-separated list rather than token-terminated list is a complicated pattern in the first place and the very definition includes a special case. There is always n-1 separators, unless there is 0 items, in which case there is also 0, not -1 separators. We as programmers know what it's like to write code that joins a string or writes out a comma-separated rather than terminated list. Either the last or the first item is always a special case.

I'm not saying you should or will put a comma at the end of your one-line arguments or tuples. I won't. We like to see a comma-separated list surrounded by parentheses. The trailing comma is ugly. But when it gets to multiple lines, it starts getting useful. As our statements get replaced by expressions, setters get replaced by constructor arguments, with tuples and generally C# becoming more expression-oriented,
commas are the new semicolon. Code like this is going to be more and more common:

return (
    ResourceProvider.Instance.GetElectricityPrice(resources.electricity),
    ResourceProvider.Instance.GetWaterPrice(resources.water),
    ResourceProvider.Instance.GetGasPrice(resources.gas)
    );

C# already allows trailing comma in enums, array and object initializers. My proposal is to also extend this to all comma-separated parenthesized lists in the language.

This would also introduce another way to disambiguate a one-tuple expression (though I would still probably prefer to name the tuple item instead). But it does seem to me like this is the fundamental reason that we can't parse that right now - if we're relying on comma separated lists, we can't be surprised that there's a special case for a 1-element tuple.

One disadvantage about is proposal is that it will introduce inconsistencies as some code will include them & some will not (but right now there's the inconsistency that there are already places in the language that allow a trailing comma).

[yaakov-h]

Related to #391

[Neme12]

To be clear: not an arbitrary number of commas and no comma in an empty list. Every item needs to be followed by a comma except for the last one, where it is optional.

The parser would be changed from parsing the first argument and then looping while it sees a comma and expecting another one to looping until it find a close paren, parsing the argument and expecting a comma, for example (with tuples) this:

if (this.CurrentToken.Kind != SyntaxKind.CloseParenToken)
{
    var element = ParseTupleElement();
    list.Add(element);

    while (this.CurrentToken.Kind == SyntaxKind.CommaToken)
    {
        var comma = this.EatToken(SyntaxKind.CommaToken);
        list.AddSeparator(comma);

        element = ParseTupleElement();
        list.Add(element);
    }
}

becomes this:

while (this.CurrentToken.Kind != SyntaxKind.CloseParenToken)
{
    var element = ParseTupleElement();
    list.Add(element);

    if (this.CurrentToken.Kind != SyntaxKind.CommaToken)
        break;

    var comma = this.EatToken(SyntaxKind.CommaToken);
    list.AddSeparator(comma);
}

[Richiban]

Unfortunately it conflicts with the proposed syntax for womples, where

var x = (1,);

Would create an instance of a ValueTuple<int>, i.e. a one-element tuple.

I have to admit though that your proposal for this syntax does fit in better with the rest of C#, where in anonymous object literals, object & collection initializers trailing commas are already allowed.

[Neme12]

@Richiban
How does it conflict? It would specifically allow that to be parsed as the "womple" - that's one of the reasons I'm for this. And it would actually be consistent and allow the comma on any n-tuples, not just "womples".

I think you misunderstood the syntax I'm proposing. There wouldn't be any commas allowed on regular parenthesized expressions. (1,) would unambiguously be a tuple. So would (1,2,), but here it would still be possible without one.

[Richiban]

@Neme12 Actually, you're right! I thought that they were two features competing for the same syntax but actually they're perfectly compatible with one another. Carry on. :D

…

On 11 January 2018 at 15:11, Neme12 ***@***.***> wrote: @Richiban <https://github.com/richiban> How does it conflict? This proposal does the opposite. It would allow that to be parsed as the "womple". — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1246 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAoyjwjvn6lCiL2z96pOQmDFYgg6zbM-ks5tJiSegaJpZM4RZMtI> .

-- - Richard Gibson -

[softwaremills]

This is definitely necessary, especially in cases where you're doing something like XLinq and the constructor call would benefit from easy text reordering.

[theunrepentantgeek]

At the risk of being flamed for having a contrarian view, I don't believe that optional syntax like this has any place in the language.

Yes, I know that it's already supported in a few places, like object initializers and the like - but compounding an existing mistake by making it worse doesn't improve matters.

Before someone else brings it up - the argument that "If I don't like it, I don't have to use it" falls down as soon as you start looking at long lived codebases with multiple maintainers.

[softwaremills]

It's an incredible convenience for enabling reordering of arguments through simple text operations. Being able to select a line and move it up and down is just tremendously useful, especially in a situation like XLinq where parameter lists are being used as collection initializers.

[CyrusNajmabadi]

but compounding an existing mistake

I'm not sure how it's a mistake.

[theunrepentantgeek]

I really don't want to come across as a jerk here - while I have a strong opinion on this, there are far more important proposals for the future of C# to discuss. Also, I'm fully aware that there are very smart developers who disagree with me on this - including both the folks who made the decision on adding it to C# as a part of the object initialization syntax, and some of the dev's on my current team.

With all that said ...

My experience is that dangling commas correlate very strongly with bugs. When I see one in a code review, or when I'm modifying existing code, it prompts me to look closer. More often than not, I find a problem that's related to the same object.

Based on that experience, I'd prefer the language not accrue additional syntax that encourages further sloppiness.

[DavidArno]

@softwaremills,

This is definitely necessary...

No, it really isn't. It's arguably useful to those with a certain coding style (and my opinions on that coding style are well documented in the linked issue), but it most certainly isn't necessary.

@CyrusNajmabadi,

I'm not sure how it's a mistake.

Please reread the duplicate issue, #391 (which you were involved in), and remind yourself of the arguments of those that see trailing commas as a mistake to save us having to repeat the same conversation here.

[softwaremills]

@DavidArno You are technically correct, the best kind of correct! Yes, it isn't necessary, it just feels like it's necessary to me, and the lack of them shows up as a constant annoyance. It's hugely convenient when editing code, while it doesn't matter much when writing it.

I appreciate optional trailing commas every time I can Alt-Up or Alt-Down in property initialization without effort, even in simple text editors. Bless you, C# team!

And I curse the lack of optional trailing commas every time I have to cut and paste and fix what is otherwise a completely simple cut and paste between any lines other than the last (or the first, if your commas swing that way). Rearranging lines is an incredibly common activity when editing code. Having syntax accommodate this saves concentration for other things when concentration matters most.

As for readability, when I'm writing CSS, sometimes I write it like this:

.some-class
{
    font-size: 110%;
    font-weight: bold;
}

And sometimes I write it like this:

.some-class { font-size: 110%; font-weight: bold }

I appreciate CSS letting me put in the optional semicolon in the first place and omitting it in the second case, because in both cases, doing the other thing would hinder readability.

I would agree it's going too far to put optional trailing commas in things like type declarations or parameter declarations. But I would really appreciate optional trailing commas in function call parameter lists.

If your shop really hates optional trailing commas, just have ReSharper flag them as errors in your team policy file.

[CyrusNajmabadi]

Yeah. Looking at the other thread, i come to the same conclusion as before. Trailing punctuation has more value than problems. And, C# already recognized this with several constructs already. So it would be sensible to just allow it for all (except the small set of carved out cases where we may want to do something in the language in the future).

[DavidArno]

@CyrusNajmabadi,

I'm sure we all come to the same decision as before as this thread has offered nothing to change our minds.

To you, and ~50% of folk that have voted, trailing punctuation has more value than problems. To me, and ~50% folk that have voted, trailing punctuation has more problems than value.

Sure, trailing commas are allowed in some C# constructs already. However, as I said before, "we already made that mistake before, so what harm doing it again?" is a pretty rubbish argument. You don't see it as a mistake; I do. So from my point of view, you want to replicate that mistake. And the only reason for wanting to is because it makes it easier to write/edit code. The "consistency" argument is a strawman as everyone accepts there are situations where trailing commas either make no sense or are a breaking change. Making it easy to write code (at the expense of reading it) is a rubbish reason for a change.

You claim it would be sensible to allow it for all lists of values save for a subset where it might affect future plans. But how do you judge those scenarios? This proposal suggests allowing it for tuples. Sounds safe? Nope. consider:

Foo((1));
Foo((1,));
Foo((1,2));
Foo((1,2,));

If trailing commas had been allowed for tuples, then Foo((1,)) as a one element tuple would be a breaking change. Allowing Foo((1,2,)) now, but treating Foo((1,)) as a one element tuple would be inconsistent. Foo((1,2,)) is an optional comma; Foo((1,)) is mandatory.

Any syntax change risks closing off future ideas. This idea is no different. As you are fond of saying, every idea starts at -100 and has to work upwards. The fact that it risks closing out further ideas and is highly controversial actually sends it more negative. Is "it makes editing a bit easier" really worth all those plus points? Of course it's not. This should be a dead in the water idea. We have so many way more useful ideas to consider.

[CyrusNajmabadi]

As mentioned already: (except the small set of carved out cases where we may want to do something in the language in the future)